Add v1.13 semantic conventions #3499
Conversation
MrAlias
force-pushed
the
semconv-v1.13_2
branch
from
a3c4233 to
8df8d23
Compare
MrAlias
requested review from
jmacd,
Aneurysm9,
evantorrie,
XSAM,
dashpole,
MadVikingGod,
pellared,
hanyuancheung and
dmathieu
as code owners
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3499 +/- ##
=======================================
+ Coverage 77.9% 78.7% +0.7%
=======================================
Files 163 165 +2
Lines 11850 12277 +427
=======================================
+ Hits 9239 9666 +427
Misses 2413 2413
Partials 198 198
|
There was a problem hiding this comment.
Is the change to templates backward compatible? By this, I mean both the API hasn't changed, and the functions don't have any additional outputs. I don't think it is needed, but it would be nice to have.
If it's not, or we don't want to test extensively enough to show it, we should probably add a warning not to generate anything prior to v1.13.0
I'm not sure I follow. The change produces different attributes as the specification requires different attributes. It is therefore not a backwards compatible change in accordance with the specification. The template generation will not produce the old function sets. As we discussed in the SIG meeting a few weeks ago, instead of building complex logic to switch on an OTel spec version to build you can check out the old generation code if we wanted to generate prior versions, though I'm not sure why we want to do that though. |
I assumed this, but I wanted it to be extra clear. Can we add some documented warning that if you generate with spec version <v1.13.0 this will break things? |
Add note about compatibility. Update example TAG.
Fix #3191
Closes #3533
semconv/v1.13semconv/v1.13/httpconvto provide HTTP trace conventionssemconv/v1.13/netconvto providenetThe replacement of these previous functions comes from the refactor in the specification of the net and http semantic conventions (open-telemetry/opentelemetry-specification#2469, open-telemetry/opentelemetry-specification#2614), and a desire to make these convenience functions more ergonomic.
Open Question
I haven't included metric specific functions here. Namely because the difference is going to be in the
http.routeattribute on the server which is not generated in the span conventions. That means the current trace conventions can be used to comply with the metric conventions currently. I am not sure how we want to partition signal specific conventions in the future?